为什么选择 Apache BookKeeper - Part 1
🎙️ 阅读本文需要大约 8 分钟
Apache BookKeeper 针对实时工作负载进行了优化，是可扩展、可容错、低延迟的日志存储服务。BookKeeper 最初由雅虎研究院（Yahoo! Research）开发，而后于 2011 年作为 Apache ZooKeeper 的子项目孵化，最终在 2015 年 1 月作为 Apache 的顶级项目问世。
自最初引入以来，诸如 Twitter、Yahoo!、Salesforce 等公司广泛使用 BookKeeper 在多种用例中存储、服务重要数据。在本文中，我将介绍 BookKeeper 如何确保持久性、一致性与低延迟，还会重点介绍 BookKeeper 的保证和关键特性，这些内容都是开源的。
在上一篇文章：基础向｜Apache BookKeeper 简介中，我对 Apache BookKeeper 进行了技术层面的概述，并介绍了一些相关的概念和术语。
Bookies：一组独立的存储服务器
元数据存储系统：用于服务发现和元数据管理
BookKeeper 客户端可以使用较高级别的 DistributedLog API（也称为日志流 API）或较低级别的 ledger API。Ledger API 允许用户直接与 bookies 交互。下图即为 BookKeeper 安装的典型示例。
典型的 BookKeeper 安装（通过多个 API 连接的应用程序）
流存储要求
在上篇文章中已经提到，实时存储平台应该同时满足以下要求：
即使在强持久性条件下，客户端也能够以极低的延迟（小于 5 毫秒）读写 entry 流
能够持久、一致、容错地存储数据
在写入时，客户端能够进行流式传输或追尾传输
有效存储数据，支持访问历史数据与实时数据
BookKeeper 通过提供以下保证来同时满足上述各项要求：
多副本
BookKeeper 在一个数据中心内的多个机器上，或是多个数据中心之间，复制每条数据记录并存储多个副本（通常是 3 个或 5 个副本）。
一些分布式系统使用主/从或管道复制算法在副本之间复制数据（例如，Apache HDFS、Ceph、Kafka 等），BookKeeper 的不同之处在于使用 quorum-vote 并行复制算法来复制数据，以确保可预测的低延迟。下图即为 BookKeeper 集成中的多副本。
在上图中：
1. 从 BookKeeper 集群中（自动）选择一组 bookies（图例中为 bookies 1-5）。这一组 bookies 即为给定 ledger 上用于存储数据记录的 ensemble。
2. Ledger 中的数据分布在 bookies 的 ensemble 中。也就是说，每条记录都存有多个副本。用户可以在客户端级别配置副本数，即写入 quorum 大小。在上图中，写入 quorum 大小为 3，即记录写入到 bookie 2、bookie 3 与 bookie 4。
3. 客户端向 ensemble 中写入数据记录时，需要等待直至有指定数量的副本发送确认（ack）。副本数即为 ack quorum 大小。接收到指定数量的 ack 后，客户端默认写入成功。在上图中，ack quorum 大小为 2，也就是说，比如 bookie 3 和 bookie 4 存储数据记录，则向客户端发送一条确认。
4. 当 bookie 发生故障时，ensemble 的组成会发生变化。正常的 bookies 会取代终止的 bookies，这种取代可能只是暂时的。例如：如果 Bookie 5 终止，Bookie x 可能会取代它。
多副本：核心理念
BookKeeper 多副本基于以下核心理念：
1. 日志流面向记录而不是面向字节。这意味着，数据总是存储为不可分割的记录（包括元数据），而不是存储为单个字节数组。
2. 日志（流）中记录的顺序与记录副本的实际存储顺序分离。
这两个核心理念确保 BookKeeper 多副本能够实现以下几项功能：
为向 bookies 写入记录提供多种选择，从而确保即使集群中多个 bookies 终止或运行缓慢，写入操作仍然可以完成（只要有足够的容量来处理负载）。可以通过改变 ensemble 来实现。
通过增加 ensemble 大小来最大化单个日志（流）的带宽，以使单个日志不受一台或一小组机器的限制。可以通过将 ensemble 大小配置为大于写入 quorum 大小来实现。
通过调整 ack quorum 大小来改善追加时的延迟。这对于确保 BookKeeper 的低延迟十分重要，同时还可以提供一致性与持久性保证。
通过多对多副本恢复提供快速再复制（再复制为复制不足的记录创建更多副本，例如：副本数小于写入 quorum 大小）。所有的 bookies 都可以作为记录副本的提供者*与*接受者。
持久性
保证复制每条写入 BookKeeper 的数据记录，并持久化到指定数量的 bookies 中。可以通过使用磁盘 fsync 和写入确认来实现。
1. 在单个 bookie 上，将确认发送给客户端之前，数据记录已明确写入（启用 fsync）磁盘，以便在发生故障时能够持久保存数据。这样可以保证数据写入到持久化存储中不依赖电源，可以被重新读取使用。
2. 在单个集群内，复制数据记录到多个 bookies，以实现容错。
3. 仅当客户端收到指定数量（通过 ack quorum 大小指定）的 bookies 响应时，才 ack 数据记录。
最新的 NoSQL 类型数据库、分布式文件系统和消息系统（例如：Apache Kafka）都假定：保证最佳持久化的有效方式是将数据复制到多个节点的内存中。但问题是，这些系统允许潜在的数据丢失。
BookKeeper 旨在提供更强的持久性保证，完全防止数据丢失，从而满足企业的严格要求。
一致性
保证一致性是分布式系统中的常见问题，尤其是在引入多副本以确保持久性和高可用时。BookKeeper 为存储在日志中的数据提供了简单而强大的一致性保证（可重复读取的一致性）：
如果记录已被引用程序 ack，则必须立即可读。
如果记录被读取一次，则必须始终可读。如果记录 R 成功写入，则在 R 之前的所有记录都已成功提交/保存，并且将始终可读。
在不同读者之间，存储记录的顺序必须完全相同且可重复。
这种可重复读取的一致性由 BookKeeper 中的 LastAddConfirmed（LAC）协议实现。
高可用
在 CAP（Consistency：一致性、Availability：高可用、Partition tolerance：分区容错）条件下，BookKeeper 是一个 CP 系统。
但实际上，即使存在硬件、网络或其他故障，Apache BookKeeper 仍然可以提供高可用性。为保证写入与读取的高可用性能，BookKeeper 采用了以下机制：
低延迟
强持久性和一致性是分布式系统的复杂问题，特别是当分布式系统还需要满足企业级低延迟时。BookKeeper 通过以下方式满足这些要求：
在单个 bookie 上，bookie 服务器旨在用于不同工作负载（写入、追尾读、追赶读/随机读）之间的I/O 隔离。在 journal 上部署 group-committing 机制以平衡延迟与吞吐量。
采用 quorum-vote 并行复制 schema 缓解由于网络故障、JVM 垃圾回收暂停和磁盘运行缓慢引起的延迟损失。这样不仅可以改善追尾延迟，还能保证可预测的 p99 低延迟。
采用长轮询机制在 ack 并确认新记录后，立刻向追尾的写入者发出通知并发送记录。
最后，值得一提的是，明确 fsync 和写入确认的持久性与可重复的读取一致性对于状态处理（尤其是流应用程序的 effectively-once 处理）非常重要。
总 结
本文解释了 BookKeeper 如何保证其持久性、一致性、高可用与低延迟。希望本文为你选择 BookKeeper 作为实时工作负载存储平台提供了强有力的支持。
在后续文章中，我会深入介绍 BookKeeper 如何复制数据，以及它采用了怎样的机制能够在保证低延迟时，同样保证一致性与持久性。
想要了解更多关于 Apache BookKeeper 项目的信息，请访问官方网站：
http://bookkeeper.apache.org
想要随时掌握 Pulsar 的研发进展、用户案例和热点话题吗？快来关注 Apache Pulsar 和 StreamNative 微信公众号。